In article <3a8a6369@news.povray.org> , Warp <war### [at] tagpovrayorg>  
wrote:

>   You make it sound like most compilers (specially gcc) have extremely
> poor support for STL; that it's almost impossible to make anything according
> to the C++ standard because the standard-conforming STL implementation is
> almost inexistent.

Yes, and the support is really poor, but not in the teams you are
talking about - you missed my point completely.

I mentioned gcc as one _example_ (because I didn't want to write a too
long response), but many other compilers have the same problem (i.e.
Visual C, CodeWarrior, etc).  The point is _not_, I repeat is _not_,
that _one_ compiler is not fully standard compliant, but that hardly any
compiler gets at least the important (read: the stuff I want to use)
stuff right.  Now, in order to write anything portable you first have to
make sure you know about all the missing features in every
compiler/library combination you want to use, then you can hope to find
a usable subset of available functions and classes.  Add yet another
compiler/library combination later and you have to do it all over again.
This is hardly something I consider a useful _cross-platform_ library.

>   I would like to note that this is not true.
>   I have been coding for more than 2 years with gcc using STL (as my work,
> not just as hobby). It is true that there are some things missing (like
> string iterators), but mostly the STL implementation conforms to the standard
> and is very usable.

Yes, I use the STL frequently (for example in the POV-Ray 3.5 Mac
frontend), but I do not remember a case when I did not have to make
changes to code (taken straight from the ISO C++ standard document or
Stroustrup's book) when trying to compile other STL programs under
Visual C++, gcc and CodeWarrior (see below).  Let me note that these are
the three compilers the team is using for Windows, Linux and Mac OS
respectively.  The Visual C++ library is a mess when it comes to string
support (seems to have to do with making it compatible with MFC, I
guess), in gcc iostreams are more distant from the standard than
anything else (not to mention the template problems they even admit to
have on their website!) and CodeWarrior comes with a nice and nearly
complete library but every not-so-frequently-used function seems to have
bugs you have to fix first it or wait half a year for them to do it (and
did I complain that an average compile of a medium sized program can
take 100 MB of memory if it is using templates?).

Or, just look at the endless number of compiler specific ifdefs in the
SGI STL.  Ever wondered why they are needed?  Surly not because all
compilers even remotely support a common subset of "simple things" like
template support.

>   Among other "exotic" things in the STL, I have used stream iterators,
> iterator traits, functors, predicates and several "exotic" utilities
> (such as bind1st, bind2nd, etc), and they all work as the C++ standard states.

As said above, I never said you cannot use the STL with a single
compiler/library combination!

Take the "povdocgen" utility (in the Perforce depot) for example.  It
only uses string, vector, list and algorithm and is 1700 lines.  It took
several hours to find out just what is causing gcc to not like it.  And
still, this does not mean that it will work with Visual C++.  The code
is really primitive and uses only the simplest features of the STL in a
minimal manner.  And it takes hours to port to another compiler/library
combination.  Granted, we will develop POV-Ray 4 on the major platforms
simultaneously, but still consider this scenario:

Someone submits a change to the code.  You download it and try to
compile.  You get errors because some STL class member function does not
even exist.  Now you have to find a workaround using another member
function.  This takes you lets say two hours.  Then you submit your
change.  With a bit of luck it still works for the person who submitted
the original change.  A third person downloads it, has to make changes
for his compiler, and submits the change.  How likely is it now that it
still works for the first person or you?  How much time was spend to
sort this out that could have been used doing some real work?  How much
testing and team communication overhead do we introduce by this kind of
issues?  Or, how long will it delay a release?

>   And this is not all. The STL implementation used by gcc is (at least
> partially) very efficient.

Yes, my local STL is really fast, too, but what is all the speed good
for if it is still not portable? - Nothing, if you are talking about
cross-platform code...


      Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message